The Security Common Functions (SEC_CF) over application layer in OMA aims to provide a common set of security mechanism that can be re-used by OMA enablers. The rationale behind this SEC_CF is to avoid, where possible, duplication of security effort for each OMA Enabler that requires security functionality. SEC_CF offers to re-use both the architectural entities (e.g. Security Gateways, etc) and security specifications (e.g. protocol profiles) when developing new OMA enablers. OMA enablers typically comprise of protocols, such as MLP (Mobile Location Protocol), RLP (Roaming Location Protocol), PCP (Privacy Checking Protocol) in the Location enabler, SSI (Server-to-Server Interface) and CSI (Client-to-Server Interface) in the Presence enabler, SyncML in Device Management, or PAP (Push Access Protocol), which is used by multiple enablers.
The current version of the SEC_CF, i.e. Security Common Function Version 1.0 (referred to as SEC_CF v1.0 hereinafter), is designed to provide security functionality only for OMA enablers that operate over TCP as the transport protocol, not for those OMA enablers over UDP, such as enabler CPM (Converged IP Messaging). Since OMA SEC_CF v1.0 using TLS/PSK-TLS to provide security functionality, it is not applicable for those OMA enablers over UDP.
Although the user plane security can reuse the media security in 3GPP, the development of the related media security standards are too late and CPM could not wait, since these media security standards are not ready yet. Therefore, it is very urgent to improve SEC_CF and make it applicable for those OMA enablers that operate over UDP as the transport protocol.
Considering ESP (Encapsulating Security Payload) which specified by RFC 4303 is a key protocol in the IPsec (Internet Security) architecture, which is capable of providing confidentiality and integrity for both TCP and UDP, we believe IPSec ESP is the best choice to be utilized for supporting security functionality for UDP-based OMA enablers. Data Integrity herein refers to a security service that protects against unauthorized changes to data, including both intentional change or destruction and accidental change or loss, by ensuring that changes to data are detectable. Data Confidentiality herein refers to the property that a particular data item or information (usually sent or received as part of the content of a “secured” message, or else constructed on the basis of exchanged data) is not made available or disclosed to unauthorized individuals, entities, or processes, and remains unknown to the intruder.
In the existing IPSec ESP, before providing security service for the traffic data, a secure communication channel between the initiator and the responder must be established via a security association (SA) set-up procedure. The general SA set-up procedure is designed based on an assumption that the two endpoints of the secure communication channel, i.e. the initiator and the responder, are strange to each other, and thus takes a complicated procedure to set up SA. (More details on the general SA set-up procedure will be described later with reference to FIG. 2)
However, in OMA SEC_CF, the two endpoints of the secure communication channel are not completely strange to each other. In other words, the two endpoints may known each other via some other security mechanisms previously, such as via an authentication and key agreement in underlying network infrastructure. Thereby, the general procedure to set up SA according to the prior art is unefficient for adapting IPSec ESP to current OMA SEC_CF.
Thus, it would be an advancement in the art to adapt IPSec ESP to current OMA SEC_CF v1.0 to make SEC_CF useful for enablers based on UDP, in a manner that attempts to optimize the SA set-up procedure and protocol efficiency.